Librem 5, un projet de téléphone mobile libre tournant sous GNU/Linux !

Posté par Bofil . Édité par Davy Defaud, Pierre Jarillon et patrick_g. Modéré par bubar🦥. Licence CC By‑SA.
Étiquettes :
45
24
sept.
2017
Téléphonie

C’est en lisant un article sur le site Generation-NT) que j’ai appris l’existence d’un projet de téléphone mobile tournant sous PureOS, une distribution GNU/Linux basée sur Debian. Comme l’explique l’article, « son idée est de se focaliser sur le logiciel libre, la sécurité et le respect de la vie privée. » Le rêve ! De plus, KDE se raccroche au projet afin de proposer Plasma (oui, je suis fan de KDE/Qt depuis des années), mais il y aura aussi GNOME, a priori.

La société derrière ce projet, Purism, a ouvert une campagne de financement participatif jusqu’au 23 octobre 2017 (si j’ai bien compté) avec pour objectif de lever 1 500 000 US$. Au moment ou j’écris cet article, ils ont levé 511 630 US$, soit 34 % de la somme attendue.

Les objectifs du projet sont détaillés dans la suite de l’article.

Le téléphone mobile sera capable de faire tourner des applications HTML 5, mais dans les questions‐réponses sur le site de Purism dédié au projet, il est expliqué qu’il est prévu de faire tourner des applications Android dans un second temps.
La distribution GNU/Linux prévue est, comme je le disais, PureOS, mais rien n’empêchera de faire tourner d’autres distributions comme Debian, Ubuntu, Suse, Fedora, Arch Linux, etc.

La configuration matérielle prévue est la suivante :

  • écran de 5 pouces (technologie et définition non précisées) ;
  • processeur mobile i.MX6 ou i.MX8 de NXP (Freescale) à architecture ARM, avec une isolation entre la partie chargée de la téléphonie et le processeur ;
  • processeur graphique Vivante avec pilotes libres ;
  • 3 Gio de mémoire vive ;
  • 32 Gio d’espace de stockage (extensibilité non précisée) ;
  • capteur photo arrière et avant ;
  • prise Jack ;
  • connecteur USB type C ;
  • Compatible 2G/3G/4G : GSM, UMTS et LTE ;
  • Wi‐Fi ;
  • Bluetooth ;
  • capteurs:
    • GPS,
    • accéléromètre,
    • gyroscope,
    • boussole,
    • détecteur de lumière ambiante,
    • capteur de proximité.

Aller plus loin

  • # Rapport performance / prix décevant

    Posté par  . Évalué à 10.

    Projet intéressant, mais je trouve que le tarif est excessivement élevé (600$) pour un appareil qui n'existe pas encore, il ne sortira qu'en janvier 2019, et dont les caractéristiques techniques sont déjà dépassées par les smartphones d'aujourd'hui. Surtout, au niveau matériel il n'apporte rien de neuf, contrairement au Fairphone par exemple.

    De plus, on ne sait pas à quel degré le travail logiciel sera transposable à d'autres smartphones.

    J'aurais bien soutenu le projet, mais c'est au-dessus de mes moyens par rapport à ce que ça apporte.

    Je préfère voir aboutir une initiative comme Halium (https://halium.org/) qui permettrait d'utiliser diverse distributions GNU Linux sur des smartphones lambda, et ainsi laisser libre l'utilisateur de choisir son matériel en fonction de ses besoins et de ses moyens.

    • [^] # Re: Rapport performance / prix décevant

      Posté par  . Évalué à 9. Dernière modification le 24 septembre 2017 à 14:45.

      Tout à fait d'accord, l'initiative est bonne mais le hardware dépassé et le prix font qu'il ne faut pas en attendre des miracles.

      J'ai l'impression que la seule plus-value du téléphone est qu'il est libre, bof. Là je réitère mes propos, pourquoi pas un feature phone libre pour commencer. Dans la mesure où on est à la base sur un marché d'extrême niche avec ce produit pourquoi ne pas pousser cette logique jusqu'au bout sur l'objet en proposant tout de même quelque chose d'intéressant économiquement pour le fabricant et l'utilisateur. On passe donc grâce aux faibles coûts sur une potentielle démocratisation, ce qui est il me semble, le but du libre. A 600 boules on démocratise rien du tout et donc on protège quasi personne. Dans le pire des cas si le marché visé est prêt à acheter un téléphone juste parce qu'il est libre il y a tout de même plus de chances que ce soit le cas à 100 qu'à 600. Ça peut être aussi un excellent téléphone de travail aussi et viser les entreprises.

      Concernant les specs sur un feature phone on s'en contrefiche (si ce n'est la batterie) et ça c'est une bonne chose. On pourrait se plaindre de la non présence d'internet sur un feature phone écran e-ink mais si vraiment c'est indispensable pour certain rien n'empêche de prévoir un navigateur de type links pour le texte, au moins y'a de l'info.

      Bref je trouve que toutes ces volontés de créer des smartphones (comme le librem 5 ou le fairphone) suréquipés libres sont intéressantes et instructives mais on se fourvoie non? Expliquez-moi en quoi j'ai tort s'il vous plaît

      • [^] # Re: Rapport performance / prix décevant

        Posté par  . Évalué à -5.

        L'idée est bonne mais rien que pour l'exemple quand on voit que l'appareil n'a même pas de flash pour l'appareil photo pour le prix c'est du foutage de gueule quoi!

        • [^] # Re: Rapport performance / prix décevant

          Posté par  (site web personnel) . Évalué à 4.

          Il ne faut exagérer non plus, le téléphone est cher pour ce qu’il est mais il possède un flash et tout ce qu’on attend classiquement d’un téléphone.

          Après il faut savoir que le prix ne comprend pas que le prix du matériel mais bien aussi tout le développement qu’il y a autour (logiciel comme matériel).

          Et d’après ce que j’ai compris, contrairement au projet halium, le but est d’utiliser un GNU/Linux classique adapté au téléphone plutôt que de partir d’Android.

          • [^] # Re: Rapport performance / prix décevant

            Posté par  . Évalué à 2.

            Après il faut savoir que le prix ne comprend pas que le prix du matériel mais bien aussi tout le développement qu’il y a autour (logiciel comme matériel).

            Bref, comme pour tous les produits, non ?

            • [^] # Re: Rapport performance / prix décevant

              Posté par  (site web personnel, Mastodon) . Évalué à 6.

              Oui et Non, car les autres ont amortis le prix sur des milliard de vente. Mais si demain tu veux les concurrencer tu ne peux pas. La seul solution c'est de changer le design et d'ajouter et de racheter les pièces aux autres constructeurs… Tu aura quoi? Moins bien que les autres…

              Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.

            • [^] # Re: Rapport performance / prix décevant

              Posté par  . Évalué à 6.

              Oui comme tous les produits. Sauf que les coûts de R&D c'est un coût fixe qui plombe le prix de vente unitaire dans des marchés de niche. Le problème de volume se répercute aussi sur le prix de fabrication. Un cercle vertueux pour les ténors du marché, un cercle vicieux pour les petites entreprises.

          • [^] # Re: Rapport performance / prix décevant

            Posté par  . Évalué à 3.

            Et d’après ce que j’ai compris, contrairement au projet halium, le but est d’utiliser un GNU/Linux classique adapté au téléphone plutôt que de partir d’Android.

            Qu'est-ce que tu veux dire par là ? Que Halium utilise le noyau Linux Android ?
            C'est obligatoire pour faire fonctionner le matériel.
            Purism contourne le problème en utilisant du matériel dont ils pourront avoir les pilotes. Mais en contre partie, c'est du matériel dépassé et cher. De plus, ce travail ne sera pas transposable aux autres SoC.

            L'idéal serait d'avoir des SoC plus standard et surtout des pilotes ouverts que l'on puisse intégrer au noyau Linux original, mais il n'y pas suffisamment de demande pour que ça intéresse les fabricants visiblement.

            Ce projet serait intéressant s'il visait à financer du matériel libre ou au moins plus ouvert. Mais là, on a pas d'innovation matérielle et il n'apporte pas grand chose aux projets déjà existant au niveau logiciel. J'ai du mal à voir quel sera le vrai apport. Une suite de d'application mobile ? Ça semble limité :

            Our first version will be focusing on phone calling, encrypted communication, and web browsing.

            Ils ne vont pas concevoir leur propre environnement graphique avec ce financement :

            We will be working with both GNOME/GTK and KDE/Plasma communities, and have partnered with the foundations behind them for the middleware layer. PureOS currently is GNOME-based and our great experience with working with GNOME as an upstream as well as GNOME’s OS and design-centric development model; however we will also test, support, and develop with KDE and the KDE community, and of course we will support Qt for application development. We will continue to test GNOME and Plasma, and should have a final direction within a month after funding success. Whatever is chosen, Purism will be working with both communities in an upstream-first fashion.

            Si ça permet un grande avancée dans le développement de Plasma et Gnome sur mobile et enfin avoir quelques chose de vraiment mature, tant mieux. Mais je ne suis pas sûr que cette façon de financer ces développement soit la plus efficace. On verra bien.

          • [^] # Re: Rapport performance / prix décevant

            Posté par  . Évalué à 0.

            Je n'ai pas vu de flash sur la vidéo de présentation, à moins que je sois complétement bigleux (oud distrait) :D

            Et je vois pas comment on peut utiliser Gnu/Linux sur un écran de cette taille, c'est dèjà compliqué pour ceux qui ont utilisés des netbooks de 7"…

      • [^] # Re: Rapport performance / prix décevant

        Posté par  . Évalué à 3.

        un feature phone libre écran e-ink

        Ça me plairait vachement quand mon Nokia C2 sera mort !

      • [^] # Re: Rapport performance / prix décevant

        Posté par  . Évalué à 2. Dernière modification le 24 septembre 2017 à 21:45.

        J'ai l'impression que ce qui plombe les coûts c'est de trouver un SOC conforme avec une volonté de matériel libre. Sans même parler d'Open Hardware, ce qui bloque au niveau logiciel libre c'est principalement la partie pilote graphique. Le Freescale i.MX est la solution la plus proche de l'idéal et il n'y a pas vraiment d'autres possibilités actuellement. Le prix du SOC est peut-être prohibitif.

        Je vois tout à fait le potentiel et l'architecture en terme de composants d'un feature phone à 90% libre (sauf le modem GSM/GPRS/LTE/WCDMA etc.) et réparable facilement, mais est-ce que le prix sera aussi attractif et est-ce que le fait d'avoir un matériel aussi basique intéressera suffisamment de gens ? Il faudra sans doute une bonne campagne marketing.

      • [^] # Re: Rapport performance / prix décevant

        Posté par  (site web personnel, Mastodon) . Évalué à 1.

        Il faut savoir ce que l'on veux. Si l'on a du matériel libre c'est forcément plus cher au moins au départ car il y a beaucoup a développer. Le Fairphone, c'est du marketing. Rien n'est libre donc qui me garantit quoi que ce soit même l'OS est peut-être muni de backdoor made in NSA.
        En fait en téléphone libre il existe que du très basique non smartphone et encore, il faut le fabriquer (mais il est pas trop cher : 60 euros contre 10 dans le commerce…).

        Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.

    • [^] # Re: Rapport performance / prix décevant

      Posté par  (site web personnel, Mastodon) . Évalué à 3.

      Pour un Feature Phone, il faudrait toujours faire tourner Linux dessus, assembler le matériel (probablement en produisant moins de machines que la plupart des autres fabricants au début), etc. En fait, au final, vu que l'OS est déjà prêt pour lancer des applications, faire un téléphone capable de le faire, ça coûte pas forcément plus cher.

      Conclusion: à mon avis, un feature phone préparé et produit de la même façon ne coûterait pas forcément beaucoup moins cher. Après on pourrait partir dans une autre direction pour avoir un matériel beaucoup moins puissant, pas de 4G, etc. Peut-être en laissant tomber Linux et en se dirigeant vers Rockbox, par exemple. Mais j'ai du mal avec le concept d'un téléphone libre où on ne pourrait pas installer une application dessus. ça va être compliqué de vendre ça aux gens: "oui alors, sur ce téléphone ci, qui est libre, tu dois tout recompiler si tu veux ajouter une nouvelle fonctionalité. Sur l'iPhone tout-verrouillé-propriétaire à côté, tu vas juste sur l'app store et en 3 clics tu as l'application installée".

    • [^] # Re: Rapport performance / prix décevant

      Posté par  (site web personnel) . Évalué à 2.

      tu t'attendais à quoi?

      un 16 coeur avec 8 gig de ram pour 400 euro?

      ils ont pas le volume de samsung ou bien de apple, ni les moyens, ni les fournisseur

      le volume est faible forcément ça coûtera plus cher à produire… principe même de l'offre et la demande…. quand même pas besoin d'un bac + 12 pour comprendre ça

      www.solutions-norenda.com

      • [^] # Re: Rapport performance / prix décevant

        Posté par  . Évalué à 10. Dernière modification le 25 septembre 2017 à 14:23.

        quand même pas besoin d'un bac + 12 pour comprendre ça

        Ce qui me semble encore plus facile à comprendre, c'est qu'on ne peut pas vendre un appareil plus cher et moins performant que les concurrents, sauf à avoir une très très bonne raison de le faire. Toute la discussion porte donc autour de l'idée qu'une base partiellement ou complètement libre, c'est une très très bonne raison, ou non.

        Personnellement, tous ces projets de téléphone libre, ça ne me semble pas très sérieux. Quel est le business model? La cible doit être aisée (autrement, on ne dépense pas autant dans un téléphone), sensibiliseé au LL et aux problèmes de vie privée, pas trop geek-matériel (parce que le matos n'est pas au niveau), très geek-logiciel (parce qu'il va y avoir des bugs et un catalogue d'applications vide), pas intéressée par l'économie et la pérénité de la chose (parce que bon, sans business model, dans 6 mois ça aura coulé)… Tout ça me semble complètement paradoxal ; les gens qui connaissent un peu l'affaire et qui attendent depuis des années des appareils libres savent que le développement associé est super casse-gueule, et que des grandes boites du logiciel libre (Mozilla, Ubuntu…) s'y sont cassées les dents.

        On pourrait imaginer un business model basé sur la sécurité : on vend des portables pas très performants, mais complètement sécurisés (la cible pourrait être des entreprises, etc). On pourrait aussi avoir une cible différente des "gros", avec des portables d'entrée de gamme, qui permettent quelques fonctions de base sans pour autant permettre d'installer des jeux (et ça permettrait d'éviter de parler de la taille du catalogue d'applications…).

        principe même de l'offre et la demande

        Le principe de l'offre et de la demande, pour moi, ça veut dire qu'on peut vendre plus cher quelque chose qui est très demandé, et on doit baisser les prix quand on n'a pas de clients. Bref, exactement le contraire de ce que tu suggères.

        ils ont pas le volume de samsung ou bien de apple

        On reproche souvent à Apple leurs marges considérables. C'est pas un peu paradoxal d'expliquer qu'on ne peut pas s'aligner sur leurs prix à cause des coûts de production?

        De toutes manières, à mon avis, l'argument est peu vendeur. L'épicerie du coin de la rue est plus chère que le supermarché, mais on y va parce que c'est pratique, que c'est ouvert plus tard le soir, etc ; bref, le consommateur n'a pas besoin de la raison pour laquelle le prix est plus élevé, il a besoin d'une raison pour accepter de payer plus cher. Ici, la seule raison, c'est le libre, et c'est le seul argument pertinent. On pourrait éventuellement invoquer des usines dont les employés sont mieux traités que les enfants chinois des usines d'Apple, par exemple, ça pourrait être un argument. Mais quelque chose comme «mes concurrents sont mieux organisés que moi et arrivent à des coûts de production inférieurs, ce qui leur permet de vendre moins cher que moi tout en ayant des meilleures marges», ça donne presque envie d'aller voir ailleurs, non?

        • [^] # Re: Rapport performance / prix décevant

          Posté par  (site web personnel, Mastodon) . Évalué à 2.

          On reproche souvent à Apple leurs marges considérables. C'est pas un peu paradoxal d'expliquer qu'on ne peut pas s'aligner sur leurs prix à cause des coûts de production?

          Tu as de la chance: le financement est en crow funding. Ça veut dire que tu peux payer 1200€ pour un seul téléphone si tu souhaites vraiment être aligné aux prix d'Apple :-)

          Si non, l'offre et la demande ça marche aussi dans ce sens: il y a peu de demande, alors l'offre sera plus cher.

          L'idée aussi est que la production de matériel a un coup considérable dû à la phase d'initialisation de la chaîne de production. Dès que la chaîne est prête, tu peux produire 1'000 ou 10'000 unités pour le même coût d'initialisation (et de recherche et développement).

          Comme ce n'est pas les pièces et matériaux qui sont chers (sauf si tu sélectionnes les matériaux comme Fairphone), alors tu peux beaucoup mieux répartir les coûts sur un grand nombre d'unités.

          • [^] # Re: Rapport performance / prix décevant

            Posté par  (site web personnel, Mastodon) . Évalué à 5.

            J'aime beaucoup le "crow funding" (littéralement, "financement par les corbeaux"). Je sais pas si c'était fait exprès, mais je garde!

          • [^] # Re: Rapport performance / prix décevant

            Posté par  (site web personnel) . Évalué à 5.

            Si non, l'offre et la demande ça marche aussi dans ce sens: il y a peu de demande, alors l'offre sera plus cher.

            Euh n'importe quoi. C'est bien connu, ce qui a du mal à se vendre, on l'augmente… C'est l'absence d'économies d'échelle sur leur petite production qui fait exploser les prix, pas une espèce d'anti-loi de l'offre et de la demande inversée à la anti-matière.

            • [^] # Re: Rapport performance / prix décevant

              Posté par  . Évalué à 2.

              La loi de l'offre et de la demande, c'est quelque chose de simple, qui permet de comprendre comment les prix et les quantités sont fixés. Essayer de lui faire dire plus que ça, c'est en effet n'importe quoi.

              Produire en petite quantité coûte cher à cause de l'absence d'économies d'échelle, ça n'a rien à voir avec l'offre et la demande. Ça veut simplement dire que quand tu es petit, tu n'es pas compétitif. Et ça, c'est tant pis pour toi, ton activité n'est pas viable, et tu vas couler, parce que la demande de produits moins bons et plus chers est, en théorie, très limitée.

    • [^] # Re: Rapport performance / prix décevant

      Posté par  . Évalué à 2. Dernière modification le 27 septembre 2017 à 02:16.

      Je préfère voir aboutir une initiative comme Halium (https://halium.org/) qui permettrait d'utiliser diverse distributions GNU Linux sur des smartphones lambda

      Bon c'est pas pour lancer un troll (mais en fait si…), mais j'observe que Halium requiert "systemd as the main init" (entre autres choses, ça évoque aussi pulseaudio, networkmanager…), donc si on souhaite une distro légère avec musl (telle que Alpine ou LEDE) j'imagine que c'est mort… Et à la question "Why is systemd involved ?" la réponse est un laconique "Some hardware functionalities (rild, sensors…) are provided by Android services, which must be started at boot time. Therefore an integration in the init system is needed." que je trouve assez peu convaincant…

      • [^] # Re: Rapport performance / prix décevant

        Posté par  . Évalué à 4.

        Bon, puisque tu veux y aller au Troll, allons-y (mais dans la bonne humeur):

        Bon c'est pas pour lancer un troll (mais en fait si…), mais j'observe que Halium requiert "systemd as the main init" (entre autres choses, ça évoque aussi pulseaudio, networkmanager…), donc si on souhaite une distro légère avec musl (telle que Alpine ou LEDE) j'imagine que c'est mort…

        Mon cellulaire, que j'ai depuis déjà 3 ans et qui tient encore bien la route, a déjà une RAM honorable de 3Go, soit presque autant que mon fixe d'il y a (ouch, ça fait mal en y pensant) 6ans, et qui fait tourner GNU/Linux/Systemd/KDE.
        Donc non, on n'a pas besoin d'être aussi léger que ça. Les smartphones ne sont plus des machines avec les contraintes de l'embarqué et du minimalisme absolu.

        Et à la question "Why is systemd involved ?" la réponse est un laconique "Some hardware functionalities (rild, sensors…) are provided by Android services, which must be started at boot time. Therefore an integration in the init system is needed." que je trouve assez peu convaincant…

        Une fois qu'on accepte que le smartphone peut très bien le supporter, quel est le problème à prendre l'init qui est maintenant le plus populaire de l'écosystème Linux, bénéficie d'un très bon support technique, et dont on n'a rien à craindre sur sa survie dans les prochaines années?

        • [^] # Re: Rapport performance / prix décevant

          Posté par  (site web personnel) . Évalué à 2. Dernière modification le 27 septembre 2017 à 23:43.

          Les smartphones ne sont plus des machines avec les contraintes de l'embarqué et du minimalisme absolu.

          Sur les contraintes physiques (typiquement la compatibilité électromagnétique), si. Sur les grandeurs "simples" telles que la quantité de RAM, tu as raison, clairement non, en tout cas les modèles pour occidentaux raisonnablement aisés. Sur les aspects intermédiaires, à voir. Genre, le surcoût en RAM de systemd (et franchement j'attends de le voir parce que dans le genre fantasme…) non, mais son surcoût en terme de cycles CPU et donc de drain de batterie ?

          • [^] # Re: Rapport performance / prix décevant

            Posté par  . Évalué à 3.

            Ici, on ne parle que de l'OS, pas du matériel.

            Sur un smartphone, l'usage va être forcément très différent (quoi que?), mais sur mon petit Kimsufi KS1, systemd <= 0.1% CPU.
            Je doute que ce soit apparent dans le Pareto du drain de batterie.

        • [^] # Re: Rapport performance / prix décevant

          Posté par  . Évalué à 1.

          Bon, puisque tu veux y aller au Troll, allons-y (mais dans la bonne humeur):

          Évidemment (j'ai oublié de mettre un smiley, mais ça allait de soi :)

          Mon cellulaire, que j'ai depuis déjà 3 ans et qui tient encore bien la route, a déjà une RAM honorable de 3Go

          Le mien a 8Go et est plus puissant que mon fixe, mais ça ne me fait pas changer d'avis : oui n'importe quelle machine Android "décente" (je pense que même un vieux Galaxy S2 ou une tablette chinoise à 60€ entre dans cette catégorie) a largement assez de RAM et de CPU pour faire tourner une distro basée sur systemd. Je n'ai rien contre systemd dans l'absolu (je l'utilise sur ma xubuntu et je comprends qu'il puisse plaire) mais j'ai quelque chose contre systemd imposé car ça reste plus difficile à comprendre/maîtriser (et debugger quand/si ça foire), et surtout car ça réduit drastiquement le choix (j'aime particulièrement bien musl, et je sais générer ma distro avec la toolchain openwrt). Si systemd était en mesure de supporter musl je ne serais pas aussi sévère mais Lennard refuse de résoudre le problème

          • [^] # Re: Rapport performance / prix décevant

            Posté par  . Évalué à 4.

            Je n'ai rien contre systemd dans l'absolu (je l'utilise sur ma xubuntu et je comprends qu'il puisse plaire) mais j'ai quelque chose contre systemd imposé car ça reste plus difficile à comprendre/maîtriser (et debugger quand/si ça foire), et surtout car ça réduit drastiquement le choix (j'aime particulièrement bien musl, et je sais générer ma distro avec la toolchain openwrt). Si systemd était en mesure de supporter musl je ne serais pas aussi sévère mais Lennard refuse de résoudre le problème

            Ce que tu appelles "imposé" est un choix techniques fait par les développeurs. Je suis persuadé qu'ils ont fait ce choix en connaissance de cause et qu'il leur semble pertinent.
            De même, on pourrait regretter que tout se focalise sur le noyau Linux Android alors que certains téléphones sont peut-être capables de faire tourner le noyau Linux standard. Ce n'est pas qu'il est imposé, mais c'est ce que cette équipe développe.

  • # Du mieux mais...

    Posté par  . Évalué à 6.

    Intégrer Plasma Mobile plutôt que l'idée illusoire de développer un Gnome Mobile pour l'occasion me semble un pas dans la bonne direction.

    Mais où en est Plasma Mobile? Il est utilisable au quotidien? Qui va financer le plan d'accélération du développement et l'intégration de Matrix?

    Comme je l'écrivais dans le journal: 1.5M$ c'est déjà très peu pour couvrir le développement du matériel et une petite prod!
    Ils devraient commencer par prendre un OS un peu plus fini. Dans les candidats libres, je crois qu'il ne reste que Tizen et Ubuntu Touch s'il n'est pas déjà abandonné…

    • [^] # Re: Du mieux mais...

      Posté par  . Évalué à 1.

      Difficile de savoir où en est vraiment Plasma mobile. Ils avaient un prototype prometteur en 2015 sur Nexus 5 (vidéo disponible sur le site officiel https://plasma-mobile.org/), mais pas de nouvelle démo depuis.
      Pour ce qui est de l'utilisabilité, ils la décrivent comme "solid" sur l'échelle suivante : "Excellent", "Good", "Solid", "Base works", "Experimental", "Very Experimental".
      Il n'y a pas d'autres modèles de smartphone officiellement supportés, mais Halium devrait accélérer les chose si ça abouti.

    • [^] # Re: Du mieux mais...

      Posté par  . Évalué à 2.

      Intégrer Plasma Mobile plutôt que l'idée illusoire de développer un Gnome Mobile pour l'occasion me semble un pas dans la bonne direction.

      Pourquoi ?

      • [^] # Re: Du mieux mais...

        Posté par  . Évalué à 10.

        Gnome Mobile part de zéro.
        Il y a du travail à faire sur Gtk. Il y a du travail à faire sur chacune des applis que tu veux porter sur mobile. Il n'y a pas de pile pour gérer la téléphonie.

        Ne sous-estime pas le boulot nécessaire pour faire un système mobile:

        Ubuntu y a englouti une fortune, on ne sait pas combien exactement, mais disons une bonne équipe de dévs à temps plein.
        Jolla avait levé 200M€ pour sortir un téléphone dont le matériel était à peu de chose près ce sur quoi leurs ingés travaillaient chez Nokia, et un OS largement basé sur MeeGo, qu'ils connaissaient aussi. Ça ne partait pas de 0 du tout, et ils ont englouti 200M€.
        Tu penses faire quoi avec 1.5M€?

        Gnome Mobile, ça pourrait être un bon projet.
        Gnome Mobile prêt à être vendu comme système principal pour un téléphone dans les 2ans, à moins d'avoir des millions à y engouffrer pour faire travailler des équipes à plein temps dessus, ça n'arrivera pas!

        Même Plasma Mobile est une grosse incertitude à ce niveau, alors qu'ils ont déjà une démo depuis 2ans.

        Si tu veux lancer un nouveau téléphone, utilise ce qui existe déjà, pas ce qui pourrait exister si les planètes s'alignent et que tout le monde se met à bosser pour toi gratuitement. Ou alors ne lève pas 1.5M€, mais plutôt 150M€!

        • [^] # Re: Du mieux mais...

          Posté par  . Évalué à 2.

          Non Jolla n'a pas levé 200 M de $ mais plutôt 60 M si j'en crois cet article d'Antti Saarnio
          https://medium.com/zipperglobal/startup-funding-can-be-disrupted-with-tokens-62acbce99bd0

          Pour le moment, je continue de miser sur Jolla. Certes ce n'est pas 100% "libre" mais cela reste un produit alternatif et cela va globalement quand même dans le "bon sens" à mon humble avis: https://blog.jolla.com/xperiax-open-source-hw-adaptation/

          Pour le moment mes finances ne me permettent pas d'investir dans le Xperia X et Sailfish X. J'espère cependant que d'autres smartphone suivront. Pour le moment je reste en Jolla 1 qui est toujours maintenu au niveau de Sailfish OS (la 2.1.2 est en cours et un déploiement pourrait bien avoir lieu d'ici fin octobre).

          • [^] # Re: Du mieux mais...

            Posté par  . Évalué à 3.

            Non Jolla n'a pas levé 200 M de $ mais plutôt 60 M si j'en crois cet article d'Antti Saarnio

            Une de nos sources est mauvaise:
            https://www.wsj.com/articles/SB10000872396390444592404578032153748969228
            Mais je ne saurais dire laquelle!

            Cela dit, ça ne change pas grand chose: Librem compte boucler son projet avec 1.5M$!

            Je trouve aussi Jolla prometteur, mais le côté "on libère progressivement mais pas forcément tout tout de suite", ça me rebute un peu. Ça fait quand même quelques années, et sur leur site, on n'a jamais une description claire de ce qui est libre ou pas, et rien non plus en termes d'objectifs de libération.

            • [^] # Re: Du mieux mais...

              Posté par  (site web personnel) . Évalué à 3.

              Pour les licences, ils ont fait un beau graphique pour montrer ce qui est libre, ou pas : https://sailfishos.org/about/ Cela me semble donc clair.

              Je trouve aussi Jolla prometteur, mais le côté "on libère progressivement mais pas forcément tout tout de suite", ça me rebute un peu

              C'est un soucis, mais j'avais cru comprendre que les contrats russes et chinois qu'ils ont signé imposent une libération du code (pour des raisons de souveraineté nationale). On verra bien.

              Seule la partie compatibilité avec Android n'est pas sûre de devenir libre car c'est un composant extérieur à l'entreprise Jolla.

              • [^] # Re: Du mieux mais...

                Posté par  . Évalué à 6.

                Pour les licences, ils ont fait un beau graphique pour montrer ce qui est libre, ou pas : https://sailfishos.org/about/ Cela me semble donc clair.

                Ah, au temps pour moi, je ne l'avais pas trouvé!
                C'est effectivement clair!

                Mais du coup, de ce que je vois, presque tout ce qu'ils ont codé est toujours sous licence propriétaire. C'est leur code!?
                Ah part la volonté, qu'est-ce qui les empêche de libérer leur code? Je croyais qu'ils avaient au moins libéré leur interface graphique, mais non, c'est encore totalement fermé!

                Si j'en crois ce graphique, la seule chose qui soit vraiment libre, c'est… ce qui vient directement de l'écosystème GNU/Linux!

                Et les contrats russes et chinois ne me rendent pas si optimistes: EUX vont peut-être recevoir les sources, mais pas forcément le reste du monde!

                • [^] # Re: Du mieux mais...

                  Posté par  . Évalué à 2.

                  En fait, d'après ce que j'ai compris, le code appartient surtout à leurs actionnaires. Et autant les gens chez Jolla sont plutôt pro-ouverture (beaucoup de devs sont contributeurs au libre), autant les actionnaires semblent rester de marbre.

                  Pour la partie libre du code, n'oublions pas qu'ils sont les principaux contributeurs à Mer, qui est un gros morceau. Beaucoup d'éléments de Mer sont réutilisés dans d'autres projets.

                  A ma connaissance, depuis la naissance de Jolla, seul le navigateur a été libéré. Tout le monde se plaint de la stagnation des applis fournies par Jolla (mail, calendrier, maps…); au début je voulais bien comprendre qu'ils sont une petite structure et que c'est pas évident, mais après 4 ans il faut bien se rendre à l'évidence: ils voient ça comme une perte de temps.

                • [^] # Re: Du mieux mais...

                  Posté par  (site web personnel, Mastodon) . Évalué à 3.

                  C'est donc moins libre qu'Android, en fait. Bon à savoir…

                  • [^] # Re: Du mieux mais...

                    Posté par  . Évalué à 0.

                    C'est possible…. et encore faudrait regarder de près.
                    En attendant j'ai pas besoin de compte Google ni de Google Play ;-)

                    • [^] # Re: Du mieux mais...

                      Posté par  (site web personnel) . Évalué à 9.

                      Tu peux utiliser un Android sans compte Google en le synchronisant sur un fournisseur Cal/CardDav tiers et en utilisant f-droid par exemple.

                      • [^] # Re: Du mieux mais...

                        Posté par  (site web personnel, Mastodon) . Évalué à 3.

                        Tout à fait. C'est un peu confusionnant chez Google mais il y a AOSP (Android Open Source Project) qui est le système avec quelques applications de base. Puis, il y a la version "officielle" de Google qui ajoute les applications Google, etc, et qui idéalement, ne devrait être considérée que comme une surcouche constructeur parmi d'autres. Sauf que du coup, il y a peu de contributions aux applications de base d'AOSP (je ne sais pas si c'est parce que les gens qui essaient de contribuer se font jeter ou juste parce que personne en dehors de Google ne contribue) et elles sont souvent remplacées, soit par celles de Google, soit par autre chose (par exemple LineageOS a sa propre application appareil photo si ma mémoire est bonne).

                        • [^] # Re: Du mieux mais...

                          Posté par  . Évalué à 4.

                          Google développe Android de manière privée, et maintient de moins en moins d’applications libres car remplacées par des applications Google au fil du temps. C’est pourquoi CyanogenMod/LineageOS a développé Eleven (lecteur de musique) et continue de maintenir la galerie par exemple.

                          AOSP se borne de plus en plus au cœur d’Android, là où toutes les applications de base: lanceur, clavier, agenda, appareil photo, galerie, lecteur de musique, etc.; deviennent des applications Google.

                          Sinon il faut respecter un certain nombre de conditions pour pouvoir vendre un téléphone avec le Google Play, et ça implique d’embarquer un nombre toujours plus important d’applications Google.

                          Écrit en Bépo selon l’orthographe de 1990

                          • [^] # Re: Du mieux mais...

                            Posté par  (site web personnel) . Évalué à 1.

                            C'est très intéressant mais je ne vois pas trop ce que peuvent faire les restrictions de Google pour avoir le droit d'utiliser Play sur un sous-fil où on cherche à ne pas utiliser Play.

                            Et puis c'est marrant sur un site qui sort KISS à tout bout de champ de voir comme critique d'un OS qu'il n'a pas de client de courriel ou lecteur de vidéos.

                          • [^] # Re: Du mieux mais...

                            Posté par  (site web personnel, Mastodon) . Évalué à 2.

                            On est bien d'accord, merci pour ces précisions.

                            Au final, on a quand même un OS avec AOSP et plusieurs distributions dont LineageOS qui viennent y ajouter des applications. Et au final on a quand même un système libre avec des applications (qu'il faut maintenir et faire évoluer, certes).

                            Pour moi c'est donc déjà largement mieux que Jolla/Sailfish, pour le moment. Même si c'est encore loin d'être parfait.

        • [^] # Re: Du mieux mais...

          Posté par  (site web personnel) . Évalué à 2. Dernière modification le 30 septembre 2017 à 12:09.

          C'est peut-être une question profane mais, quelles sont les spécificités mobiles auxquelles GNOME ne répond pas déjà ?

          Naïvement je me serais dit que la plupart des besoins sont déjà là. La plupart des applis GNOME sont designées de telle sorte à pouvoir être utilisés à la souris ou via un écran tactile (que j'utilise déjà). J'imagine qu'il faudrait quelques adaptations, et développer des appli pour téléphoner mais que ce serait tout.

          Qu'est-ce que j'oublie ?

  • # Siouplé

    Posté par  . Évalué à -6.

    La distribution prévue est , comme je le disais, PureOS, mais rien n'empêchera de faire tourner d'autres distributions comme Debian, Ubuntu, Suse, Fedora, Arch Linux, etc…

    Et les ennuis commenceront.

  • # Matrix

    Posté par  (site web personnel) . Évalué à 8.

    Ce téléphone a aussi la particularité de vouloir être "IP-native". Ce que ça signifie c'est que pour toutes les fonctionnalités de communication, un service IP sera mis à avant par rapport aux classiques services GSM (SMS, voix). Et techniquement, ça sera basé sur Matrix ! Ce téléphone est donc l'occasion d'un partenariat entre Purism et la fondation Matrix.org.

    Il existe deux catégories de gens : ceux qui divisent les gens en deux catégories et les autres.

  • # Dommage que la fondation Mozilla n'ai pas fait pareil avec Firefox os

    Posté par  . Évalué à 5. Dernière modification le 24 septembre 2017 à 17:51.

    La fondation Mozilla aurait du faire la même chose pour promouvoir Firefox-OS.
    S'ils avaient lancé un financement participatif pour un bon ou très téléphone sous cet OS, de nombreux geek et développeur du monde entier auraient suivi. Au lieu de cela ils ont visés le bas de gamme et marchés émergents. C'est selon moi leur plus grosse erreur.
    La volonté d'utiliser un smartphone avec OS alternatif et des applications qui préservent la vie privée n'est l’apanage que de certaines personnes militantes et éduquées. Pour Les personnes plus modestes, la marque est une critère de choix primordial. Ils préfèreront des Samsung bas de gamme ou des copie chinoise au look d'iPhone, des Nike, des polo Lacoste mais dans tous les cas fuiront comme la peste les téléphones d'entré de gamme avec un OS confidentiel dessus.

    Pour en revenir au Librem 5 et au financement participatif, lancer un téléphone ex-nihilo est un Connerie Bêtise. Ils feraient mieux de passer un accord avec un des nombreux fabricants chinois de smartphones pour spécifier un matériel adapté à leur exigences et se concentrer sur le logiciel. Pour exemple, un Xiaomi coûte moins de 200€ un processeur haut de gamme, 4 Go de RAM 64 Go de ROM, un écran 5.5' full-HD, un gyroscope, un accéléromètre et un lecteur d'empreintes et j'oubliais l'appareil photo très correct.
    Avec les 600$, je ne vois pas bien ce qu'ils espèrent. Ou alors ils visent clairement les personnes qui "se la pète" en exhibant des smartphones coûteux.

    • [^] # Re: Dommage que la fondation Mozilla n'ai pas fait pareil avec Firefox os

      Posté par  . Évalué à 5.

      Ils feraient mieux de passer un accord avec un des nombreux fabricants chinois de smartphones pour spécifier un matériel adapté à leur exigences et se concentrer sur le logiciel. Pour exemple, un Xiaomi coûte moins de 200€ un processeur haut de gamme, 4 Go de RAM 64 Go de ROM, un écran 5.5' full-HD, un gyroscope, un accéléromètre et un lecteur d'empreintes et j'oubliais l'appareil photo très correct.

      …sauf qu'en gros tu as le choix entre un SoC Qualcomm ou un SoC Mediatek, et que l'un comme l'autre nécessitent généralement de nombreux blobs binaires (=> autant prendre un téléphone existant avec lineageos dans ce cas…)

      Bon par contre : Purism pourrait effectivement commencer par porter PureOS sur un téléphone existant et supporté par Replicant. Il y a des chances qu'un vieux i9300 n'ait pas à rougir face au smartphone qu'ils veulent fabriquer…

    • [^] # Re: Dommage que la fondation Mozilla n'ai pas fait pareil avec Firefox os

      Posté par  . Évalué à 2. Dernière modification le 24 septembre 2017 à 20:03.

      (commentaire posté en double par erreur. Je peux l'éditer pour mettre ce message à la place, mais apparemment pas le supprimer…)

      --
      Moi quand je n'ai rien à dire je veux qu'on le sache… :)

    • [^] # Re: Dommage que la fondation Mozilla n'ai pas fait pareil avec Firefox os

      Posté par  . Évalué à 10.

      Un de leurs arguments de vente, ce sont les multiples interrupteurs physiques qui permettent de garantir que ton GPS est bien coupé quand tu le veux, ton Bluetooth, et ainsi de suite.

      Un autre de leurs arguments c'est d'être "entièrement Libres".

      Je suis partiellement d'accord avec toi:

      • soit ils mettent la partie matérielle en avant et ils devraient utiliser un OS "tout prêt".
      • soit ils mettent en avant leur OS et ils devraient reprendre du matériel existant

      Vu que l'OS était d'abord un "Gnome Mobile" dont on ne sait pas trop comment il aurait été développé: apparemment ils n'ont pas même vérifié la faisabilité de la chose avant de se lancer…
      https://linuxfr.org/nodes/112531/comments/1711343
      il ne reste qu'à faire du matériel!

      C'est ce qu'ils connaissent le mieux: ils font déjà des ordis portables avec un jeu d'interrupteurs.

      Et ils devraient aller chercher un OS "tout prêt" mais entièrement Libre.
      C'est sans doute là que ça devient très compliqué:

      • Android est sur une pente savonneuse. Il est toujours plus fermé à chaque version, et son principal atout, son immense catalogue d'applications, nécessite d'installer des éléments non Libres pour être pleinement exploité.
      • Ubuntu Touch est abandonné par Ubuntu. Difficile de savoir si la communauté derrière pourra le maintenir en vie
      • Sailfish est "pas entièrement Libre", donc pas Libre et j'ai de plus en plus de doutes sur l'intention de Jolla de vraiment changer ça. Je ne comprends pas pourquoi ils n'ont pas déjà libéré l'interface, s'ils sont tellement favorables à l'opensource?
      • Firefox OS est mort
      • Tizen: d'après sa page Wikipedia, Tizen a de fortes bases opensource, mais il semble y avoir des choses un peu particulières, avec des clauses sur les brevets liées à la certification Tizen, et Samsung semble aussi ajouter des SDK propriétaires.

      Il ne reste que Plasma Mobile, porté par KDE, qui a déjà réussi l'exploit de proposer une démo assez complète sans le support d'une grosse institution.

      Finalement, ce qu'il y a à retenir, c'est l'état désastreux des OS Libres pour mobile!

      • [^] # Re: Dommage que la fondation Mozilla n'ai pas fait pareil avec Firefox os

        Posté par  . Évalué à 2.

        Finalement, ce qu'il y a à retenir, c'est l'état désastreux des OS Libres pour mobile!

        Mais heureusement, sur le librem on devrait pouvoir installer Debian, Archlinux, Fedora voire Emmaübuntus-Debian et son skin qui-se-voudra-plus-léger.

        Ça fait rêver!

        En fait, le monde du FOSS ne veut pas de téléphone libre, du moins, fonctionnel.

        • [^] # Re: Dommage que la fondation Mozilla n'ai pas fait pareil avec Firefox os

          Posté par  . Évalué à 2.

          Tu di sa paske t'es pas un vraix hacker. Moi j'suis supair exitai de pouvoir optimisez ma gentoo en recompillant tous sur le telemalin diraictment. En plus mon peti frere il sora pas comant envoyai un sms dans bash, hihi.
          Mé je vai pas achete se telemalin, il es tro tro cher, et an plus il a pas de por vga, ou de por serie, et ça c'et comme meme redhibitoire, paske jpeux pa l'utilise pour me conaictai au pc qui sert de routeur, et l'administrais.

          Depending on the time of day, the French go either way.

          • [^] # Re: Dommage que la fondation Mozilla n'ai pas fait pareil avec Firefox os

            Posté par  . Évalué à 1.

            Après lecture, je pense que certains aient pu manquer mon ironie, ce qui expliquerait les plussages étonnants alors que je sous-entend la même chose que ce commentaire plus haut.
            Car je suis pas du tout jouasse à l'idée d'avoir des EmmaUbuntus-Debian et autres kadors du "skinning" qui viennent se la raconter en intégrateur du dimanche pour ce téléphone.

            Donc Kévin F. on est sur la même longueur d'onde sinusoïdale. :P

      • [^] # Re: Dommage que la fondation Mozilla n'ai pas fait pareil avec Firefox os

        Posté par  . Évalué à 6.

        Android est sur une pente savonneuse. Il est toujours plus fermé à chaque version, et son principal atout, son immense catalogue d'applications, nécessite d'installer des éléments non Libres pour être pleinement exploité.

        Google play et les apps Google nécessitent des éléments non libres. Mais si tu te restreins à F-Droid (donc à un catalogue bcp plus limité, mais pas plus limité que les autres OS évoqués), Android reste aussi ouvert que les autres OS dont on parle ici. Les parties non libres (essentiellement les blobs/drivers) sont de toute façon un souci quel que soit l'OS car

        ce qu'il y a à retenir, c'est l'état désastreux des OS Libres pour mobile!

        J'aurais dit avant tout : l'état désastreux du support libre (et sans blob) dans les SoCs modernes.

        P.S. : il est déjà parfaitement possible d'installer Debian dans un chroot sur Android (Par contre pour l'affichage accéléré ou OpenGL on repassera…)

      • [^] # Re: Dommage que la fondation Mozilla n'ai pas fait pareil avec Firefox os

        Posté par  (site web personnel) . Évalué à 6.

        Android est sur une pente savonneuse. Il est toujours plus fermé à chaque version, et son principal atout, son immense catalogue d'applications, nécessite d'installer des éléments non Libres pour être pleinement exploité.

        Disons que l'avantage d'Android est d'être bien géré par les fabricants (ce n'est pas négligeable) et que sa compatibilité avec l'écosystème applicative est très bonne. Après il y a beaucoup de non libre dans ces applications. Mais tu peux les installer sans Google Play (techniquement suffit de récupérer les APK et les mettre à disposition ailleurs, ce que certaines boutiques Android font par ailleurs).

        Cela restera au choix de l'utilisateur de faire du libre complet ou non (comme sur une distribution sur nos ordinateurs aujourd'hui).

        Sailfish est "pas entièrement Libre", donc pas Libre et j'ai de plus en plus de doutes sur l'intention de Jolla de vraiment changer ça. Je ne comprends pas pourquoi ils n'ont pas déjà libéré l'interface, s'ils sont tellement favorables à l'opensource?

        Je pense que l'entreprise n'a pas une position claire sur le sujet car si beaucoup d'employés voire dirigeants sont favorables, ce n'est pas le cas de tout le monde. On verra bien de ce qui sera fait. En tout cas cela va vers plus d'ouverture que l'inverse ce qui reste positif (même si une libération complète serait l'idéale).

        Tizen: d'après sa page Wikipedia, Tizen a de fortes bases opensource, mais il semble y avoir des choses un peu particulières, avec des clauses sur les brevets liées à la certification Tizen, et Samsung semble aussi ajouter des SDK propriétaires.

        Tizen est chapeauté par la Linux Foundation, je voudrais bien des liens sur la question des brevets car selon moi cela n'a pas de sens / n'est pas vrai.

        Possible que Samsung ajoute une petite surcouche proprio. Mais le reste du système est libre, l'essentiel est disponible en tout cas (notamment pour l'interface graphique et les applications de base). Je pense sincèrement que cela reste un bon candidat qui a l'avantage d'avoir un constructeur qui a beaucoup investi le sujet et ne risque pas de le lâcher demain (après tout télé + montres vendus avec, téléphones bien vendus en Inde / Bangladesh et tensions avec Google rendant une indépendance à terme souhaitable).

        Je pense que d'avoir des contributeurs hors Samsung (il y en a déjà, mais il en faut plus) aiderait justement à ce que le projet ne soit pas phagocyté par l'entreprise. Et que cela avance plus vite.

        Finalement, ce qu'il y a à retenir, c'est l'état désastreux des OS Libres pour mobile!

        Je pense que cette situation est due à plusieurs facteurs, que tu connais certainement mais je les rappelle.

        L'architecture ARM est un gros merdier alors qu'il domine sur les tablettes et téléphones. Son avantage de son faible coût et de sa faible consommation pour une puissance raisonnable l'ont rendu incontournable. Mais faute de BIOS ou équivalent disponible (l'UEFI arrive petit à petit mais c'est long et pas généralisé sur l'ARM64) rend toutes ces puces légèrement incompatibles avec le voisin avec peu de possibilités simples pour avoir un système unique qui s'adapte à la machine.

        Si les PCs avaient connus la même situation, cela aurait été difficile. Imagine s'il fallait une image Linux spéciale pour les HP, Dell, Acer ou autres, voire entre HP avec un Intel i386 et AMD compatible i686. Je doute que Linux en serait là aujourd'hui. Car cela aurait complexifié la venue de contributeurs et d'utilisateurs et les développeurs perdraient du temps à gérer cette situation plutôt que d'ajouter des fonctionnalités intéressantes.

        D'autant plus que le problème des téléphones est exacerbé par le fait que les fondeurs de puces type Qualcomm, Broadcom font du mauvais travail. Linux gère leur téléphone mais ce travail est fait à l'arrache faute de temps et de budget. Ce qui fait que le noyau Linux officiel ne peut bénéficier de ces travaux et peut difficilement fonctionner sur ces puces.

        Bref, s'il était facile d'installer un système Linux standard sur la plupart des téléphones, je suis presque sûr que certains systèmes type Firefox OS, Ubuntu Touch ou Tizen auraient décollé (ou décollé plus tôt).

        L'autre soucis est une question d'API. Un téléphone aujourd'hui a des applications de base que n'importe quel développeur libre peut faire. En soit ce n'est pas le soucis. L'appareil photo, le téléphone, les SMS, le navigateur Web, etc. En général tu as des versions libres suffisantes pour le job. Le soucis est pour les applications tierces.

        Car sur téléphone, le Web s'est fait détrôné par les applications dédiées. Les gens ne consulte pas (ou du moins très rarement) Youtube via leur navigateur, leur compte en banque ou les horaires de train avec le navigateur. Trop lent, ergonomie différente, besoin d'accéder à des infos pour être efficaces que le navigateur n'offre pas forcément (de quoi payer, la géolocalisation, etc.). Ces applications sont vitales pour beaucoup d'utilisateurs. Et c'est là que la collection d'applications compte. Car les éditeurs ne vont pas proposer 25 000 versions pour chaque système.

        Sur l'ordinateur ce n'est pas un soucis, nous avons le navigateur Web qui est compatible avec ces services facilement. Mais sur téléphone, comme cela passe par des API internes au service qui ne sont pas libres, tu ne peux pas le faire forcément. Je ne connais pas l'API pour consulter mon compte en banque, donc impossible de créer ma version libre de l'application officielle. Donc pour contourner cela, il faut refaire l'API d'iOS ou Android sur les autres systèmes. Ce qui n'est pas trivial même si Android a publié cela. S'il fallait par exemple un WINE parfaitement fonctionnel sous nos distributions favorites pour accéder à tous les services proposés par le Web, Linux n'en serait pas là aujourd'hui non plus.

        Cela change la donne quand même.

        • [^] # Re: Dommage que la fondation Mozilla n'ai pas fait pareil avec Firefox os

          Posté par  (site web personnel, Mastodon) . Évalué à 3.

          L'architecture ARM est un gros merdier alors qu'il domine sur les tablettes et téléphones. Son avantage de son faible coût et de sa faible consommation pour une puissance raisonnable l'ont rendu incontournable. Mais faute de BIOS ou équivalent disponible (l'UEFI arrive petit à petit mais c'est long et pas généralisé sur l'ARM64) rend toutes ces puces légèrement incompatibles avec le voisin avec peu de possibilités simples pour avoir un système unique qui s'adapte à la machine.

          Si les PCs avaient connus la même situation, cela aurait été difficile. Imagine s'il fallait une image Linux spéciale pour les HP, Dell, Acer ou autres, voire entre HP avec un Intel i386 et AMD compatible i686. Je doute que Linux en serait là aujourd'hui. Car cela aurait complexifié la venue de contributeurs et d'utilisateurs et les développeurs perdraient du temps à gérer cette situation plutôt que d'ajouter des fonctionnalités intéressantes.

          D'autant plus que le problème des téléphones est exacerbé par le fait que les fondeurs de puces type Qualcomm, Broadcom font du mauvais travail. Linux gère leur téléphone mais ce travail est fait à l'arrache faute de temps et de budget. Ce qui fait que le noyau Linux officiel ne peut bénéficier de ces travaux et peut difficilement fonctionner sur ces puces.

          Moui… Pour moi c'est plutôt Linux qui a mis beaucoup trop de temps à réagir et à mettre en place les device trees pour les architectures ARM. Résultat, les constructeurs n'ont pas eu trop de choix que de bricoler avec ce qu'ils avaient sous la main.

          Le BIOS n'y est pour rien, dans les PC il n'est quasiment pas utilisé par Linux (un peu par GRUB, mais c'est tout) et sur la plupart des machines ARM tu vas trouver un u-boot qui fait tout aussi bien et même mieux dans la plupart des cas (rappelons que le BIOS ça date des années 70, quand même).

          La différence avec les PC, c'est la présence du bus PCI qui permet d'énumérer le matériel, et auparavant de l'ISA plug-n-play. Sur ARM, il n'y a pour l'instant (en général - on trouve des machines avec un bus PCI) pas d'équivalent pour ça. Du coup, la solution c'est le device tree, qui décrit le matériel et qui normalement permet d'utiliser le même noyau partout.

          L'autre souci, c'est que pour Linux, tous les drivers devraient être intégrés dans le git de Linus Torvalds pour être maintenus. Mais ce n'est pas une approche réaliste pour plein de cas. Du coup, chaque fabricant préfère vivre avec son propre fork du noyau, ce qui coûte moins cher à court et moyen terme (et il y a peu de fabricants qui maintiennent leurs puces sur le long terme - c'est plus simple de les remplacer par des versions plus récentes).

          Si Linux avait une API stable pour les drivers et qu'on pouvait les maintenir séparément et indépendamment de la version du noyau, ça serait simple de garder les drivers du fabricant et de mettre à jour le noyau.

          Au final, pour un fabricant de puces, ça coûte moins d'effort de faire un truc rapide et pas propre et pas intégrable, et y'a pas vraiment de raison de faire autrement.

          • [^] # Re: Dommage que la fondation Mozilla n'ai pas fait pareil avec Firefox os

            Posté par  (site web personnel) . Évalué à 6.

            Moui… Pour moi c'est plutôt Linux qui a mis beaucoup trop de temps à réagir et à mettre en place les device trees pour les architectures ARM. Résultat, les constructeurs n'ont pas eu trop de choix que de bricoler avec ce qu'ils avaient sous la main.

            Devicetree ou pas, les constructeurs qui ne s'investissent pas upstream font de la merde, tout simplement. Le devicetree n'est qu'une petite partie du problème, je vais l'expliquer après.

            Le devicetree ne servant qu'à décrire ce qui est dispo sur la carte, ce n'est pas un pilote, ni un sous-système du noyau (là où résident l'essentiel des problèmes).

            Le BIOS n'y est pour rien, dans les PC il n'est quasiment pas utilisé par Linux (un peu par GRUB, mais c'est tout) et sur la plupart des machines ARM tu vas trouver un u-boot qui fait tout aussi bien et même mieux dans la plupart des cas (rappelons que le BIOS ça date des années 70, quand même).

            Sur ARM il y a beaucoup de choses à encoder en dur pour chaque plateforme car cela manque clairement d'unicité. Sur PC, soit tu as des possibilités d'énumérations, soit les processeurs sont suffisamment proches pour que cela ne pose pas une grande difficulté.

            Si Linux avait une API stable pour les drivers et qu'on pouvait les maintenir séparément et indépendamment de la version du noyau, ça serait simple de garder les drivers du fabricant et de mettre à jour le noyau.
            Au final, pour un fabricant de puces, ça coûte moins d'effort de faire un truc rapide et pas propre et pas intégrable, et y'a pas vraiment de raison de faire autrement.

            Oui et non.

            Oui, je le reconnais que c'est un problème, ça complexifie la tâche, c'est évident.

            Mais ce n'est pas dit que cela résolve tout non plus. Il suffit de voir ce que font les constructeurs (Texas Instrument, Broadcom ou Qualcomm par exemple) pour se convaincre qu'une API noyau stable n'est pas une solution pour eux.

            Car leur travail est globalement crade. S'ils ne codent pas proprement dans leur propre fork du noyau, je doute qu'ils fassent cet effort avec un API stable. Quand tu as dans un même sous-système d'un constructeur 4 versions du booléen, tu deviens chèvre. Bool, bool, _Bool et _bool.

            Quand ils utilisent leur propre pile réseau (ou une partie) plutôt que de changer celle du noyau et que bien sûr leur pilote en dépend entièrement, tu vois bien qu'il y a un soucis de conception.

            On sent bien que globalement les équipes derrière ça n'ont pas le temps ou les ressources de faire un travail de qualité suffisante pour inclure ça dans le noyau officiel. C'est un patchwork assez ignoble.

            Si l'absence d'API stable est un soucis, ce n'est clairement pas de cette seule responsabilité.

            • [^] # Re: Dommage que la fondation Mozilla n'ai pas fait pareil avec Firefox os

              Posté par  (site web personnel, Mastodon) . Évalué à 4.

              Quand tu as une API stable, tu peux au moins essayer de l'utiliser, et de faire ton driver crade comme tu veux de ton côté avec. Si ça marche pas, tu peux alors faire l'effort de faire des changements dans le noyau. Mais ça rend tout de suite clair dans quoi tu te lances: il va falloir récupérer les sources du noyau, le recompiler, faire les changements, puis maintenir ce fork.

              ça ne rend pas le code automatiquement de meilleure qualité hein. Mais par contre, ça force les gens à se dire "ouhlà, j'ai franchi la ligne rouge". À mon avis, ça rend juste les choses assez pénibles à faire pour que le dev se pose deux minutes et se demande s'il a pas moyen d'arriver à faire ce qu'il veut avec l'API qu'on lui a donné. Pas parce que c'est plus propre, mais parce que ça l'embête de devoir recompiler le noyau et pas juste son bout de driver.

              Dans le fonctionnement actuel, c'est un peu "voilà les sources du noyau, débrouille-toi avec ça". Et c'est considéré normal que chaque pilote écrit aie besoin de réécrire la moitié du noyau (j'ai arrêté de compter combien de fois ils ont changé la stratéglie d'allocation mémoire pour les pilotes graphiques, par exemple).

              En ce qui concerne l'unicité du matériel, ARM a fait pas mal de progrès pour tout ce qui est de base. Tu as une MMU standard, ainsi qu'un timer système pour faire tourner un scheduler. Déjà c'est pas mal. Autour de ça, il commence aussi à y avoir des standards de fait sur certains autres points. Par exemple, sur n'importe quelle plateforme ARM tu as toutes les chances de trouver une UART compatible 16C550 (la même qui pilote les ports série sur PC). Après pour les trucs plus avancés, cartes graphiques, etc, oui, c'est pas standard. Sur PC non plus, mais le BIOS dépanne en fournissant au moins un mode texte et du VESA pour pouvoir afficher des pixels sans accélération. Mais c'est pas vraiment là qu'est le gros du travail, en fait.

              C'est vrai que c'est plus diversifié que sur l'architecture PC/x86, mais quand même, ça ne me semble pas insurmontable si les choses sont faites un minimum proprement.

  • # Question conception smartphone

    Posté par  . Évalué à 2. Dernière modification le 25 septembre 2017 à 20:44.

    Pourquoi cela coûte si chers de produire un smartphone?
    Ne serait-ce pas plus économique/rentable de simplement demander aux boites qui conçoivent les raspberry pi, arduino, odroid etc de faire une carte qui embarque les modules gps, gsm, accéléromètres, etc?

    Si vous codez un logiciel sans une interface chatoyante, alors vous faites de la merde. Donation bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat

    • [^] # Re: Question conception smartphone

      Posté par  . Évalué à 10.

      Parce que les contraintes sont très différentes, et si tu ne les comprends pas quand tu commences, tu peux te vautrer lourdement bien plus tard dans le procédé.
      Tu as beaucoup plus d'éléments très sensibles (tout ce qui est GSM), tu dois isoler proprement ton antenne du bruit des autres composants.
      Tu ne peux plus choisir n'importe quel élément: ils doivent respecter une contrainte en termes d'épaisseur que n'ont pas les designs que tu mentionnes.
      Tu dois avoir une batterie embarquée
      Tu dois ajouter un écran et un boitier riquiqui face à la quantité de choses que tu comptes mettre dedans.
      Les processeurs que tu embarques sont plus puissants que les RPi, ils font de très brefs appels de courant particulièrement violents. Tu peux dimensionner ton alim et les capas autour de la batterie en fonction, mais une grosse alim, c'est bruyant: tu viens de ruiner les perfs de ta partie GSM!
      Ton processeur va chauffer, donc le boitier minuscule doit permettre d'évacuer toute cette chaleur.
      À moins que tu prennes des composants haut de gamme, ils seront assez sensibles à la température. Tu les as mis où par rapport au processeur et à l'alim? Une fois le boitier fermé, la distribution de la chaleur est comment dans l'appareil?

      Et là c'est juste en quelques secondes, en creusant un peu, on peut trouver bien plus de problèmes à résoudre qu'on n'a pas quand on design un "simple" ordinateur.

      • [^] # Re: Question conception smartphone

        Posté par  (site web personnel) . Évalué à 7.

        Tu as beaucoup plus d'éléments très sensibles (tout ce qui est GSM), tu dois isoler proprement ton antenne du bruit des autres composants.

        Normalement tu as même trois antennes si je ne me trompe pas : GSM, Wifi / Bluetooth et GPS. Et bien évidemment suivant le protocole (en fait la fréquence) et la portée souhaitée, il faudra les concevoir selon des règles précises pour éviter les interférences avec les composants voisins et avoir la forme et la taille nécessaire à une bonne émission / réception.

        On oublie aussi le micro et les enceintes, qui sont petits, donc très sensibles au bruit et ne restituent pas facilement le son correctement. C'est beaucoup de boulot d'intégration aussi.

        L'appareil photo c'est un beau morceau aussi pour avoir des images correctes dans la plupart des situations, le flash fait un gros appel de courant aussi.

        Sans oublier bien entendu que le tout doit avoir une forme agréable à la prise en main, qui ne glisse pas et ne fait pas mal. Donc certains éléments ont une place figée par design : la place du micro, du haut parleur principal, de l'appareil photo, flash, de la carte SIM, de la carte microSD, du connecteur Jack ou USB et les quelques boutons en plus. Tous ces éléments ne peuvent pas être positionnées n'importe où et sont contraignants.

        Bref, c'était juste pour te compléter un peu (travaillant pour l'embarqué, j'ai vu pas mal de ces contraintes). Le smartphone est sans doute l'appareil grand public électronique ayant le plus de contraintes à respecter et qui a de fait une conception très délicate. Faire un RPi à côté, vraiment, c'est rien. Certains de mes collègues ont fait des RPi like tout seul et très vite (genre un mois une fois les composants choisis). Un téléphone, cela me semble bien moins abordable.

        • [^] # Re: Question conception smartphone

          Posté par  . Évalué à 1.

          Merci pour vos explications, j'avoue n'avoir pas songé au bruit magnétique et autres joyeusetés. Je m'étais un peu arrêté à "tout ça (capteurs, batterie, appareil photo, etc) existe pour raspberry pi mais ni en miniaturisé ni en pré-intégré"

          Si vous codez un logiciel sans une interface chatoyante, alors vous faites de la merde. Donation bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat

        • [^] # Re: Question conception smartphone

          Posté par  . Évalué à 6.

          Normalement tu as même trois antennes si je ne me trompe pas : GSM, Wifi / Bluetooth et GPS.

          Tu oublies la bande FM et AM :)

          En réalité, depuis un bon moment les antennes sont uniques et multibandes. En utilisant des replis en zig-zag ou en étoile, comme un signal sinusoïdal avec ses harmoniques, on arrive à capter très large et il suffit ensuite de filtrer pour chaque bande. Ça utilise le principe des fractales et ça permet de concevoir des antennes polyvalentes et très compactes.

        • [^] # Re: Question conception smartphone

          Posté par  (site web personnel, Mastodon) . Évalué à 5.

          On oublie aussi le micro et les enceintes, qui sont petits, donc très sensibles au bruit et ne restituent pas facilement le son correctement. C'est beaucoup de boulot d'intégration aussi.

          Les micros: en général il y en a deux, un près de la bouche et un autre pour le bruit d'ambiance. Ensuite on fait la différence entre les sons reçus par ces deux micros pour annuler le bruit d'ambiance et transmettre uniquement la voix sur le réseau téléphonique.

          C'est juste un petit exemple de tous les trucs auxquels il faut penser pour faire un bon téléphone.

        • [^] # Re: Question conception smartphone

          Posté par  . Évalué à 3.

          genre un mois une fois les composants choisis

          Ce qui me fait penser qu'on a presque raté une autre joyeuseté: les composants vont avoir des contraintes supplémentaires en termes de consommation et de taille. Ça limite sévèrement le choix.

          Et la taille, ça n'est pas seulement l'empreinte, mais aussi l'épaisseur, sinon ton téléphone va vraiment ressembler à une brique!

    • [^] # Re: Question conception smartphone

      Posté par  (site web personnel, Mastodon) . Évalué à 4.

      On leur a demandé, ils ont fait ça: https://learn.adafruit.com/arduin-o-phone-arduino-powered-diy-cellphone/overview

      Je te laisse décider si c'est au niveau ou pas.

      (et adafruit sont plutôt bons pour ce qu'ils font, mais leur but ce n'est pas de faire des téléphones grand public).

      • [^] # Re: Question conception smartphone

        Posté par  . Évalué à 1.

        Oui c'est justement en connaissant ce projet pas récent (fais par des amateurs si je ne m'abuse) que je me suis posé cette question.
        Si des amateurs peuvent fabriquer un smartphone (certes pas aussi performant que samsung, htc, etc), je me dis, peut-être naïvement, que les professionnels travaillant pour et autour de ces nano pc, pourraient faire mieux.
        Et comme ces entreprises (hardkernel, raspberry, arduino) sont déjà dans du marché de niche, peut-être que le risque de flop serait moins grand.

        Mais maclag semble apporter la réponse qui est fort pessimiste pour l'avenir. (je ne suis pas fan d'android, apple c'est poubelle, et je trouve triste de ne pas pouvoir transformer des vieux smartphones en serveur comme avec les nano pc)

        Si vous codez un logiciel sans une interface chatoyante, alors vous faites de la merde. Donation bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat

        • [^] # Re: Question conception smartphone

          Posté par  (site web personnel, Mastodon) . Évalué à 4.

          ça dépend ce qu'on entend par "mieux". Les gens qui fabriquent le Raspberry Pi par exemple, ils ont de l'expérience pour router une carte électronique. ça fait pas la moitié d'un smartphone (écran, batterie, boîtier, appareil photo, …). Et surtout, ils ne font pas de puces électroniques de leur propre conception, donc ils ne feraient pas mieux d'un point de vue open hardware que d'autres (au mieux, ils pourraient publier les schémas de leur carte électronique). C'est l'approche que tente Purism, sachant qu'ils ont déjà plus d'expérience que Raspberry ou d'autres (ils ont fait et vendus plusieurs modèles de PC portables complets).

          Mais même comme ça, se lancer dans ce genre de projet a un coût non négligeable. Et ça c'est sans parler du développement logiciel - mais de ce côté là il semble que GNOME et KDE soient tous les deux motivés pour se lancer?

          Quant à transformer un smartphone en serveur, il n'est pas difficile d'installer Debian par-dessus une base Android pour faire ce genre de chose (en passant par debootstrap). ça manque de distributions pré-conçues pour cet usage, mais ça, on a pas besoin d'une entreprise qui se lance dedans pour le faire.

          En tout cas, la solution du Pi pour faire un ordinateur moins cher (en gros: on enlève le boîtier, on fait un truc 10 fois moins puissant) se transpose facilement au monde du téléphone. Sans même parler des certifications pour pouvoir faire du sans fil (et je pense que cela explique pourquoi le Pi a mis du temps avant d'intégrer wifi et bluetooth), et à fortiori pour se connecter au réseau GSM (il faudrait pas que ça fasse tomber les antennes relais en panne, ni que ça fasse frire le cerveau de la personne qui téléphone).

        • [^] # Re: Question conception smartphone

          Posté par  . Évalué à 2.

          Pour faire une brique GSM basique c'est pas très compliqué : un microcontroleur et un module SIM800 ou 900. Je dirai même que leur design avec des shields arduino est loin d'être optimal en compacité mais j'imagine que c'est fait avec les produits que la boutique vend. On trouve plus compact chez Olimex et il y a certainement moyen de remplacer la Li-Po par un accu 18650 standard tout en réduisant le volume de la brique.
          Par contre le module GSM est une boite noire qui gère tout mis à part l'interface et la gestion de la batterie. Il est tellement complet que pour ajouter un interrupteur manuel pour le couper électriquement tout en permettant d'utiliser l'entrée et la sortie audio (par exemple une bête fonction dictaphone ou baladeur en véritable mode avion parano sans risque de téléphone maison) ça demande un bon travail de conception.

  • # Autre système/distribution qui voit le jour

    Posté par  (Mastodon) . Évalué à 6.

    https://postmarketos.org/
    Basée sur Alpine Linux

    postmarketOS (pmOS), is a touch-optimized, pre-configured Alpine Linux that can be installed on smartphones and other mobile devices. The project is at very early stages of development and is not usable for most users yet.

    Bonne route, « postmarketOS » !

  • # Histoire de remettre les pendules à l'heure

    Posté par  . Évalué à 9. Dernière modification le 27 septembre 2017 à 10:09.

    Bryan Lunduke, un journaliste passionné de GNU/Linux, connu pour ses chroniques "Linux sucks", s'est entretenu avec Todd Weaver, le CEO de Purism. Ceux qui comprennent l'anglais réaliseront aussi que la campagne de financement de ce téléphone est prévue en plusieurs étapes, la première permettant d'obtenir une version fonctionnelle. Le développement ne s'arrête pas à la campagne de financement. Outre son avantage d'être un téléphone tournant sous GNU/Linux, il possède les caractéristiques suivantes:

    • développé par des vétérans de l'assemblage de PC portables, qui connaissent le métier d'intégration de composants électroniques pour mobiles et qui ont l'expertise logicielle adéquate;
    • pas moins de 4 "hardware kill-switch" (si j'ai bien compris), des interrupteurs pour déconnecter physiquement (ce qu'ils appellent "base band") le modem cellulaire et d'autres composants;
    • branchement d'un moniteur externe pour afficher le bureau.

    Et d'autres encore. En bref, cet appareil pourrait très bien être un bureau portable servant, accessoirement de téléphone mobile. Je serais bien tenté de traduire l'entièreté de la vidéo en français mais je crains que la campagne de financement se termine avant.

    Et, personnellement, je mettrais bien volontiers 600€ dans un téléphone comme ça, juste parce que ça existe, parce que je me réjouis que ce projet aboutisse et parce que ce n'est ni un iPhone ni un Android.

    En d'autres termes, ce téléphone mérite son financement, alors contribuons donc avant qu'il soit trop tard.

  • # Caractéristiques techniques

    Posté par  . Évalué à 3.

    D'après ce que j'ai compris de l'entretien entre Bryan Lunuke et Todd Weaver, la mémoire du téléphone est de 4Go et non 3Go (l'entretien date du 28 août, ces infos ont peut-être été mises à jour, je n'ai pas vérifié) et l'espace de stockage serait de 128Go au lieu de 32Go. La résolution correspondrait à la HD, soit 1920x1080.

  • # mardown

    Posté par  . Évalué à 1.

    Et la surcouche opérateur dans tout ça?

  • # Commentaire supprimé

    Posté par  . Évalué à 2. Dernière modification le 30 septembre 2017 à 15:02.

    Ce commentaire a été supprimé par l’équipe de modération.

    • [^] # Re: Sony met le paquet sur Jolla

      Posté par  (site web personnel, Mastodon) . Évalué à 2.

      ça fait assez longtemps que Sony publie les sources de leur noyau adapté pour AOSP (la version libre d'Android) et rend facile le déblocage du bootloader sur leurs téléphones (et même certaines smartwatches).

      C'est plutôt bien de leur part et l'une des raisons pour lesquelles j'ai acheté un téléphone de chez eux.

      D'après la news, on aura pas beaucoup mieux pour Jolla: uniquement les sources du noyau. De ce que j'ai compris, Sailfish X sera une "ROM" vendue 50 euros.

      Par contre, cela veut dire qu'on peut avoir un noyau Linux standard avec les pilotes qui vont bien dedans, et probablement essayer de faire un debootstrap (ou l'équivalent dans votre distro préférée) puis développer une interface utilisateur libre par dessus. Là, c'est aux libristes de prendre les choses en main pour la suite!

  • # c'est pas chère.

    Posté par  . Évalué à 1.

    Il existe un téléphone mobile fonctionnel accessible en France sous GNU/Linux ? Non.
    Si une bouse sous android vaut 900€ alors …
    Certes ce n'est pas à la portée de toutes les bourses mais il faut bien commencer.

  • # "Prix/performances"

    Posté par  . Évalué à 1.

    Après lecture des commentaires mettant en cause le "rapport prix performances décevant"je reste perplexe face à l'analyse des commentateurs… Aussi je salue l'objectif de ce projet qui est simplement celui d'être Libre.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.